Tighten auth failure lockout threshold#1411
Conversation
massx1
force-pushed
the
security-auth-bruteforce-lockout
branch
from
8586ea8 to
7cd8f13
Compare
| assertEquals(3, USER_SERVICE.read(userKey).getFailedLogins()); | ||
| userTO = USER_SERVICE.read(userTO.getKey()); | ||
| assertEquals(2, userTO.getFailedLogins().intValue()); | ||
| assertNotEquals("suspended", userTO.getStatus()); |
There was a problem hiding this comment.
The status value comes from the workflow definition in use, so it might vary.
The cleanest check here is
assertFalse(userTO.isSuspended();
There was a problem hiding this comment.
I guess I have to do the same thing few rows below adding assertTrue(userTO.isSuspended());
userTO = USER_SERVICE.read(userTO.getKey());
assertNotNull(userTO);
assertNotNull(userTO.getFailedLogins());
assertEquals(3, userTO.getFailedLogins().intValue());
assertEquals("suspended", userTO.getStatus());
maxAuthenticationAttempts = 3 means that the number of authentication attempts allowed to fail is 3, at maximum. So the fact that "the user was still active after 3 failures and suspended only on the 4th failure" is on purpose, not an error. |
|
@massx1 please reach out to dev@ to discuss, when you are proposing such changes, thanks. |
2 participants
Before this change, the account policy threshold was enforced on attempt N + 1: with maxAuthenticationAttempts = 3, the user was still active after 3 failures and suspended only on the 4th failure.
The old test encoded this by asserting failedLogins == 3 before executing one more failed login.